StringConcat - разработка без боли и сожалений

ВНЕЗАПНО, немного про метрики. Обычно для отслеживания работы приложений мы используем несколько приёмов:

1. Тащим все количественные штуки, которые можем найти в приложении
Количество свободных подключений в пуле БД или чём-то подобном, процент попадания в кеш, количество запросов и прочее.
Во многих случаях «ручки» для мониторинга предусмотрены заранее или даже вытащены производителями фреймворков наружу. Например, в Spring Boot можно получить инфу о состоянии пула БД.

2. Тащим временные метрики
С ними чуть сложнее. Нужно обмазывать метриками вручную каждый функциональный уровень (слой, если хотите) условной аннотацией @Timed:
— Контроллер (обычно в том же спринге метрики выведены)
— Сервисы уровня приложений
— Все внешние адаптеры, не важно, куда мы ходим, в БД или внешнюю систему

3. Тащим количество событий предметной области по каждому из типов
Служит косвенным признаком, что с системой всё хорошо. Технически всё может быть исправно, но по какой-то причине пользователи перестали жмакать кнопки, по количеству событий можем заметить, что что-то не так.

Итого, это необходимый минимум метрик для наблюдений за приложением (ну, помимо стандартных CPU и прочего). Можно раньше пользователей увидеть, что что-то идёт не так. Также можно профилировать, гонять нагрузочные тесты и хотя бы примерно понимать, где тормозит.

Есть и более хардкорный вариант — непрерывное профилирование, когда профайлинг идёт в реальном времени и можно увидеть, где, что и сколько выполнялось, примерно как в обычной IDE. Если у вас нагруженное приложение, можно попробовать эту практику, вместо того чтобы спрашивать у админов «а чо как мне тут агента подсунуть, профайлить хотим».

Telegram

Microservices | Вопросы с Собеседований

⚡Continuous profiling

Continuous profiling - техника постоянного сбора данных о ресурсах, затрачиваемых приложением

Обычно профилирование применяется как ситуативная мера, чтобы здесь и сейчас подебагать перфоманс приложения. Но это не позволяет анализировать…

www.tg-me.com/jp/StringConcat разработка без боли и сожалений/com.stringconcat/263

2.7K viewsЕвгений, Aug 26, 2024 at 11:18

ВНЕЗАПНО, немного про метрики. Обычно для отслеживания работы приложений мы используем несколько приёмов:

1. Тащим все количественные штуки, которые можем найти в приложении
Количество свободных подключений в пуле БД или чём-то подобном, процент попадания в кеш, количество запросов и прочее.
Во многих случаях «ручки» для мониторинга предусмотрены заранее или даже вытащены производителями фреймворков наружу. Например, в Spring Boot можно получить инфу о состоянии пула БД.

2. Тащим временные метрики
С ними чуть сложнее. Нужно обмазывать метриками вручную каждый функциональный уровень (слой, если хотите) условной аннотацией @Timed:
— Контроллер (обычно в том же спринге метрики выведены)
— Сервисы уровня приложений
— Все внешние адаптеры, не важно, куда мы ходим, в БД или внешнюю систему

3. Тащим количество событий предметной области по каждому из типов
Служит косвенным признаком, что с системой всё хорошо. Технически всё может быть исправно, но по какой-то причине пользователи перестали жмакать кнопки, по количеству событий можем заметить, что что-то не так.

Итого, это необходимый минимум метрик для наблюдений за приложением (ну, помимо стандартных CPU и прочего). Можно раньше пользователей увидеть, что что-то идёт не так. Также можно профилировать, гонять нагрузочные тесты и хотя бы примерно понимать, где тормозит.

Есть и более хардкорный вариант — непрерывное профилирование, когда профайлинг идёт в реальном времени и можно увидеть, где, что и сколько выполнялось, примерно как в обычной IDE. Если у вас нагруженное приложение, можно попробовать эту практику, вместо того чтобы спрашивать у админов «а чо как мне тут агента подсунуть, профайлить хотим».

BY StringConcat - разработка без боли и сожалений